home *** CD-ROM | disk | FTP | other *** search
/ Stone Design / Stone Design.iso / Stone_Friends / Wave / WavesWorld / Documentation / WW3DKit / stuff / variableTracingInWavesWorld < prev    next >
Encoding:
Text File  |  1995-03-22  |  2.6 KB  |  53 lines
  1. Variable tracing in WavesWorld is a complex subject, and not fully
  2. debugged yet.  This riff is an attempt to clear away some of the
  3. cobwebs in my mind, and hopefully kill the bugs.
  4.  
  5. When a WWTCLInterp starts up, it doesn't have any variables being
  6. traced.  When a WWInterp starts up, it adds a new command called
  7. "setReadOnly" which will automatically set up a write trace on such
  8. variables to give an error msg if an attempt is made to write a value
  9. to that variable.  It then sets the read-only variable PI and sets up
  10. a write trace on it (why do I do this by hand; why not just send
  11. myself a "setReadOnly:" msg?  Also, I should have a specific read
  12. trace, so if people haven't made it global, and try to read it it will
  13. get a value... will this fuck things with closure?  Who cares if
  14. 3.14xxx gets put in? )
  15.  
  16. When a WWEveParser gets init'ed, it allocs up a WWInterp and does a
  17. few more things.
  18.  
  19. First it set the value of "scene(incr)" and then it sets up two
  20. traces; a read and a write trace.
  21.  
  22. When the WW3DWell inits, it hooks the eveParser up with the
  23. sceneClock, it sets the value of "scene(ticksPerSecond)" to a read
  24. only value.  (One problem here - every time you set a value to
  25. read-only, it initiates a new trace on it.  This is wicked
  26. wasteful...) ((Does this still happen?))
  27.  
  28. So now we have "PI", "scene(ticksPerSecond)", and "scene(incr)" all
  29. being traced, the first two for read and last for read and write.
  30.  
  31. Now we drop a .wwModel into the well.  For each EveCmd in the model
  32. file, we perform a "closure" on the expression that the EveCmd is
  33. based on.  That closure is performed by the EveCmd's eveParser which
  34. returns a WWTCLClosedCmd object.  That object has within it a set of
  35. traces which have been set up in the parser.  Let's look at how those
  36. got instantiated.
  37.  
  38. The EveCommand hands the expression (as a string) to the eveParser and
  39. asks it to generate a closure.  The eveParser hands it to the tcl
  40. interp object.  For each global variable it finds in the expression,
  41. the interp sends a msg to itself adding a write trace on the variable
  42. using clientData, and then it sends a addTraceFor:calling:using: msg
  43. to the new closed cmd that it's building up.  One weird thing about
  44. this is that both the interp and the closed cmd *each* have a
  45. WWTCLVarTrace object corresponding to this trace.  This is potentially
  46. troubling, because if they both ask to be deleted, we could have
  47. trouble.  Do they?  What happens when an EveCommand gets free'ed?  
  48.  
  49. Well, when the EveCommand gets free'ed, it free's its closed command,
  50. cmd.  It frees its list of traces.  Each of those traces, when
  51. free'ed, removes itself from the WWTCLInterp's list of traces.
  52.  
  53.